Software Open Source in ambito industriale
0 likes648 views
This document discusses opportunities and risks related to open-source software in industrial contexts. Reusing open-source code can reduce development costs but requires carefully reviewing licenses and allocating resources to understand the code and integration risks. Releasing code as open-source may further reduce costs through community contributions but requires establishing a new business model and maintaining engagement to avoid forks. Overall, the document analyzes both reuse and release of open-source software from legal, cost, and community support perspectives for industrial software projects.
Software Open Source in ambito industriale
- 1. Better Software 2011 Software Open-Source in ambito industriale: opportunità e rischi Claudio Scordino c.scordino@evidence.eu.com Evidence Srl
- 2. Introduction
- 3. My background... • My name: Claudio Scordino • Education: – 2003 Master degree in Computer Engineering – 2007 PhD in Computer Science • Work: – 2006-2008: Linux kernel developer at Evidence Srl • 2008-2010: Code merged in the mainline Linux kernel – 2008-2011: Project Manager at Evidence Srl • 2011: ScrumMaster certification Evidence Srl: we make firmware and software for embedded, real-time and complex systems 3
- 4. Outline • Open Source and the business model • Overview of the most common open-source licenses • Reusing existing open-source code – Opportunities – Risks • Releasing our code as open-source – Opportunities – Risks • Summary 4
- 5. Open Source and the business model • Open-Source does not mean "no money" • Several companies make money working with Open-Source projects. Examples: – Google (Android, Googletest, Chrome, etc.) – Redhat, IBM • Other companies, instead, had troubles with their strategy: – Nokia – Mandrake/Mandriva Choose the right – Ubuntu ? business model! – Sun (acquired by Oracle) 5
- 7. Open Source licenses • Several Open Source lisenses exist – See http://www.opensource.org – See http://www.gnu.org/philosophy/license-list.html • Big differences between one license to another • We will see three major open source licenses: – GPL – LGPL – BSD 7
- 8. GNU General Public License (GPL) • Most popular license • Published by the Free Software Foundation • Allows to modify and redistribute (even sell) the code as long as the recipient maintains the same rights (access to the source code included) • No warranty • Modifications are and remain GPL • Examples: Linux, U-Boot, Firefox 8
- 9. GNU General Public License (GPL) (2) • In practice: – The source code must be released to the end-user, if any • No obligation to release the source code to anybody else – GPL code cannot be used inside non-free code • Use of GPL libraries in non-free programs is forbidden (unless code is for "personal usage" and not distributed) • Several versions available: – GPLv2: • The most used (e.g., Linux and U-Boot) – GPLv3: • Latest version • More restrictive (forbids deals about patent protection, hardware lock technologies and DRM) 9
- 10. GNU Lesser General Public License (LGPL) • Published by the Free Software Foundation • Usually used for libraries • More permissive than GPL: code can be linked to proprietary programs – The program linked to the LGPL code can be distributed under any chosen terms • The recipient must be given the possibility of linking the program to a modified or newer version of the LGPL library – This restriction is unacceptable in some circumstances, so some projects prefer the GPL with linking exception license • No warranty • Examples: GTK and Qt libraries, Erika Enteprise RTOS 10
- 11. BSD licenses • Family of licenses • Used for BSD by the Berkley university • Redistribution in binary form is permitted – It only requires to acknowledge the original developers – More permissive than GPL and LGPL • No warranty 11
- 13. Reusing: the appealing opportunities • Re-using existing open-source code presents a set of appealing opportunities: – Faster development with respect to code written from scratch – Lower costs (e.g., no royalties) with respect to commercial solutions – Lower (but not null) development costs – Free help and technical support by a development community – Possibility of having "branded products" (e.g., Android-based cellphones) • Success stories: mobile manufacturers using Linux, Android, U- Boot 13
- 14. Reusing: some risks • 1st issue: legal issues – E.g., Must your source code be redistributed ? – Read the licence carefully and think of all the possible scenarios to understand any possible legal issue. – In case the source code must be redistributed, you get all opportunities and risks of releasing your code as Open- Source. See the next part of the talk. • 2nd issue: Lack of full knowledge of the system – Problem shown when unexpected behaviors/bugs happen – Remember that code may have not been properly tested – Allocate one full-time person to deeply study the software 14
- 15. Reusing: some risks (2) • 3rd issue: are you enough agile ? – Open-Source projects are characterized by rapid development cycles • On the Linux kernel, on average, 7267 lines of code added every day – "Old-style" companies can have troubles in following a fast development cycle • Usually because the amount of effort has been underestimated – Allocate one full-time person to keep in touch with the development community and to follow the development cycle 15
- 16. Reusing: some risks (3) • 4th issue: how much being updated ? – Fix bugs and security holes as soon as possible • When facing a problem/bug, synchronize with the latest version before asking help to the development community • Consider letting people hacking the device when this is not a real problem (e.g., cellphones) – Suggestion: when a stable and working system is reached, evaluate if being aligned with the next versions is the right choice • Regressions are likely to happen and for mature products it's not worth the trouble! 16
- 17. Releasing as Open-Source code
- 18. Releasing: interesting opportunities • Releasing our code as Open-Source can have a set of advantages as well: – Create a development community that can provide help and support for free – Better code: more people review and improve the code – Lower development/maintainance costs – Boost collaboration with other research institutes or other companies, reducing the effort/costs – Enter new markets: change your business model from product to service to enter a market characterized by closed-source products 18
- 19. Releasing: interesting opportunities (2) – Customers of a software product have more trust: they get the source code to be able of fixing possible technical issues even in the long term – Positive image of the company • Example: Google • Free advertising • Easier to hire talented developers 19
- 20. Releasing: some risks • 1st issue: loss of strategic competitive advantage ? – Evaluate the market and your main competitors! 20
- 21. Releasing: some risks (2) • 2nd issue: decide how to drive your business model: – Often this implies changing from product to consultancy – Think about using a dual-license model to investigate if it is possible to have advantages of both worlds (i.e., commercial and open-source) • Good way to explore the market and to evaluate the strategy – Remember that once the source code is public, it is possible to go back but somebody could start a fork of the project 21
- 22. Releasing: some risks (3) • 3rd issue: future legal issues – Choose the right license carefully and think of all the possible scenarios – Choose one of the major existing licenses • Developers are afraid of licenses they don't know • Trying to inventing a new license is risky, because it requires a deep knowledge in this topic 22
- 23. Releasing: some risks (4) • 4th issue: evaluate the amount of effort needed – Coordination and collaboration with the community: • Consider time/effort to involve new developers through documentation, wikis, forums, and mailing lists. – Maintainance and technical support • Especially in the beginning phase, allocate a full-time person to answer technical questions and help people to get involved – Remember that developers stay away from projects that appear to be dead • The amount of "activity" of a project is evaluated through different metrics (e.g., number of emails/commits) 23
- 24. Releasing: some risks (5) • 5th issue: how much to drive development ? – If you do not enforce a direction, you may experience the loss of full control on the development – If you try to drive the development in a different direction than the one wanted by the community, there is the risk of a fork 24
- 25. Summary
- 26. Summary • Reusing Open-Source software in your product can really cut the development costs. However: 1. Read the license carefully and evaluate all possible scenarios 2. Remember to allocate at least one person full-time to study and test the software and to follow on-going development 3. Fix bugs and security holes immediately 4. For mature and stable products, don't jump to new versions • Releasing your software as Open-Source may reduce development costs and improve your company's image. However: 1. Evaluate your new business model and if you are losing competitive advantage 2. Consider the effort for making documentation, wiki, forums, and mailing lists. 26
- 27. Questions ? 27