Software Open Source in ambito industriale


Published on

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Open Source in ambito industriale

  1. 1. Better Software 2011Software Open-Source in ambito industriale: opportunità e rischi Claudio Scordino Evidence Srl
  2. 2. Introduction
  3. 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. 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. 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
  6. 6. Open-Source licenses
  7. 7. Open Source licenses• Several Open Source lisenses exist – See – See• Big differences between one license to another• We will see three major open source licenses: – GPL – LGPL – BSD 7
  8. 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. 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. 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. 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
  12. 12. Reusing Open-Source code
  13. 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. 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. 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. 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 its not worth the trouble! 16
  17. 17. Releasing as Open-Source code
  18. 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. 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. 20. Releasing: some risks• 1st issue: loss of strategic competitive advantage ? – Evaluate the market and your main competitors! 20
  21. 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. 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 dont know • Trying to inventing a new license is risky, because it requires a deep knowledge in this topic 22
  23. 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. 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. 25. Summary
  26. 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, dont jump to new versions• Releasing your software as Open-Source may reduce development costs and improve your companys 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. 27. Questions ? 27