Employing OSS as part of successful product

I recently attended a webinar given by Oliance Group on the success factors for use of OSS. Whilst the webinar concentrated on one particular organisations' experience, the following are my 10 points of note which should apply to any product based organisation using OSS.

1. Innovation with OSS traditionally comes from the community or vendors (where commerical success can be gained). However there is increasing innovation emerging from customers, partners, academics when OSS is used as there is an increase in collaboration as the wider benefits of OSS are now being recognised.
2. OSS is increasingly being used in non-differentiating aspects of products. A good example is the GENIVI alliance which provides an open source in-vehicle infotainment toolkit where there is non-differentiation in manufacturers products.
3. Most product organisations have recognised that it is futile to prevent OSS being used within its products and have now focused on how to best harness the benefits and opportunities that OSS offers. It is essential that the consequences of redistribution is understood when OSS is included as a component within your product - this requires a good understanding of the licences with a preference to use components released under one the permissive licences (Apache 2.0, MIT, BSD) over the copyleft (GPL family) licences. The use of some OSS components has helped its customers, partners etc in adopting and developing new products.
4. Use of OSS components/products should  often result in enhancing and fixing bugs as well as before contributing back into the community. Internal developments may benefit from being released into the community if it is a non-discriminatory development as it will re-energise the component with a better product emerging.
5. Use of OSS must not diminish customers needs for relaible, quality and secure products. Whilst OSS may offer benefits in terms of reduced development timescales, not all OSS is good and careful selection is required before it can become a key component within a product. The selection process is key to future success and in addition to assessing the licence requirements and component maturity, there needs to be an assessment of the functional fit to ensure that the OSS component is compatible with the overall product architecture and its intended use (e.g. embedded, linked, modified).
6. Governance policies are required with regards the use of and the contribution to OSS components. All stakeholders must fully understand the approach (there are too many misconceptions about use of OSS by senior management that this needs to be carefully managed). Product owners and architects must be educated and informed about all OSS usage. A knowledge base of approved porducts (and versions) should be actively maintained to avoid a proliferation of different versions (of the same product) and similar products (providing equivalent functionality).
7. Synchronising product release cycles with that of OSS products can be problematic particularly if the OSS components are released frequently to address bug fixes/security fixes. It is recommended that product release plans are aligned with OSS components (knowledge of the roadmap for each OSS component is therefore essential for this). As products often have long term support requirements, there also needs to be some guarantee that the OSS components are compatible with the same support requirements.
8. Product standards may need to be harmonized across multiple components, particularly if a UI is involved. Also a consistent approach to security should be adopted (e.g. particularly if SSO is used/required) across both OSS and internal developments. OSS components must be actively monitored for vulnerabilities and fixes applied appropriately.
9. Support for each OSS component is important, particularly when long term support is considered. Options include do nothing, but this is only of the OSS component is very mature and stable; develop skills internally; establish a maintenance activity by active engagement within the OSS community; or employ a 3rd party support service
10. Use of an OSS component within a commerical product must ensure that the organisations's intellectual property is protected and that market discriminators remain.