Not really. A major difference between Open Source and licensed programs is who bears responsibility for making changes to the program. With licensed ones it's the company and they won't let you even see the source code without permission. With Open Source it's your responsibility and you can do whatever you like apart from selling licenses on the program.
No, as there is no such differentiation in reality. Even the most highly-bespoke solution will very frequently have OTS components at its heart – see for example the BAE Systems weapons platforms that use Real Time Linux as their base operating system; and vice versa – such as SAP system implementations, which are “configured” using custom code even in the most vanilla of implementations. Whatever solution is adopted, it is crucial that it must inter-operate using open standards.
If there are test suites available for the relevant standards and the government already has infrastructure for running software solutions against the tests then there's no reason not to subject off-the-shelf software to the same requirements for standards compliance. The rest of the purchasing process can be truncated, but off-the-shelf software should still be able to score a 'passing mark' on the interoperability tests before being allowed to be considered.
Of course once a product has passed a compliance test as part of one purchasing process the same results can be shared across different government departments. There is an opportunity for cost savings in setting up a registry of off-the-shelf software and compliance test results.
Yes. Stand-alone software may have internal formats which are not standard but highly efficient. They could also be innovative and should not be prohibited. However, if it ceases to be stand-alone then the interfaces and mapping must be standard, if one exists.
If a different rationale is applied, will vendors find some lawful mechanism by which they can successfully engage in a procurement exercise and end up delivering closed standards employing COTS components as a significant part of their solution?
No, a bespoke solution should not be a back door into vendor lock in. There is nothing wrong with a bespoke solution but the data should be standardized and interoperable which means other vendors must be able to implement it. This may be especially important in the long future where a bespoke and undocumented format could hold back innovation after the initial delivery.
I don't see why there is any difference. To a degree a bespoke solution is just off-the-shelf software that the vendor has yet to sell to anyone else ...
Question
Should a different rationale be applied when purchasing off-the-shelf software solutions than is applied when purchasing bespoke solutions?
Go to question form
Responses
11968.
Dr Mark Thompson April 19, 2012, 2:27 pmThe burden of proof should be on COTS wherever possible, with significant justification required for any bespoke development whatsoever.
11980.
Wendy Cockcroft April 19, 2012, 8:48 pmNot really. A major difference between Open Source and licensed programs is who bears responsibility for making changes to the program. With licensed ones it's the company and they won't let you even see the source code without permission. With Open Source it's your responsibility and you can do whatever you like apart from selling licenses on the program.
11992.
Simon Phipps April 20, 2012, 2:41 amThe full proposal (complete with its exception clauses) seems appropriate for both in general terms.
111005.
James Forrester April 20, 2012, 12:23 pmNo, as there is no such differentiation in reality. Even the most highly-bespoke solution will very frequently have OTS components at its heart – see for example the BAE Systems weapons platforms that use Real Time Linux as their base operating system; and vice versa – such as SAP system implementations, which are “configured” using custom code even in the most vanilla of implementations. Whatever solution is adopted, it is crucial that it must inter-operate using open standards.
111042.
Rob Crowther April 22, 2012, 6:04 pmIf there are test suites available for the relevant standards and the government already has infrastructure for running software solutions against the tests then there's no reason not to subject off-the-shelf software to the same requirements for standards compliance. The rest of the purchasing process can be truncated, but off-the-shelf software should still be able to score a 'passing mark' on the interoperability tests before being allowed to be considered. Of course once a product has passed a compliance test as part of one purchasing process the same results can be shared across different government departments. There is an opportunity for cost savings in setting up a registry of off-the-shelf software and compliance test results.
111055.
Leonard Anderson April 23, 2012, 9:36 amYes. Stand-alone software may have internal formats which are not standard but highly efficient. They could also be innovative and should not be prohibited. However, if it ceases to be stand-alone then the interfaces and mapping must be standard, if one exists.
111084.
Tony Hirst April 23, 2012, 3:12 pmIf a different rationale is applied, will vendors find some lawful mechanism by which they can successfully engage in a procurement exercise and end up delivering closed standards employing COTS components as a significant part of their solution?
111095.
Floris Bruynooghe April 23, 2012, 8:38 pmNo, a bespoke solution should not be a back door into vendor lock in. There is nothing wrong with a bespoke solution but the data should be standardized and interoperable which means other vendors must be able to implement it. This may be especially important in the long future where a bespoke and undocumented format could hold back innovation after the initial delivery.
111114.
Gareth Bult April 24, 2012, 11:06 amI don't see why there is any difference. To a degree a bespoke solution is just off-the-shelf software that the vendor has yet to sell to anyone else ...
111141.
Charles-H. Schulz April 24, 2012, 5:01 pmI fail to see why there should be a difference. Two different kinds of software distributions do not alter the very nature of the software itself.